There is a perception by many organisations that their internal network is a relatively safe haven from attackers. The thought is that well configured firewall rules and regular external penetration testing of internet connections provide adequate protection for the internal network. “We are safe inside the firewall and we trust our users, so we don’t need to worry so much about hardening, patching, access control and the rest” is an all too familiar view.
However, although the security of externally facing networks has improved, we have seen a rise in social engineering, client side attacks and physical intrusions into networks as a means of bypassing these external network controls. Recent high profile cases where criminals planted rogue equipment inside networks to steal money are likely to be just the tip of the iceberg. An internal network is increasingly a more appealing target for a hacker, than a highly secured external network. Once the hacker has obtained internal access, they can sit back and look for vulnerabilities, of which there is no short supply.
For a recent seminar, I started to compile a list of common vulnerabilities found on internal networks that led to compromise of specific systems or whole networks. I started to look for common threads in the vulnerabilities Dionach had found on the numerous internal tests we have performed over the years. After spending time looking through the results of previous assignments, speaking to colleagues and drawing from my own experiences I started to realise that putting together a concise list was much harder than I thought. I started looking for examples where one vulnerability or series of vulnerabilities had led to full system, network or domain compromise. I found that I wasn’t short on specific examples. Sometimes full compromises came from very simple misconfigurations or errors. Other times, a compromise came from a highly complex chain of lower risk vulnerabilities being exploited. The common factor in all tests was that numerous vulnerabilities were always present. The examples I had collected were fascinating, however, the aim of my presentation was to give an overview of common vulnerabilities. Somehow I needed to try and summarise the issues, to list the key components, or categories of some of the more serious exploits. This started to seem like a more manageable concept.
So here it is. This is my breakdown of the key vulnerability areas that I found that lead directly to a compromise or resulted in a compromise in combination with each other.
1. Weak / Default Passwords
A close look at most internal networks reveals a significant number of weak passwords,. Everything from normal users with “complex” passwords such as “Password01” and default system credentials, such as “tomcat:tomcat” or “sa:blank”, through to the classic “test:test” or “backupexec:backupexec” domain administrator accounts. Weak passwords are a common way to easily gain unauthorised access to systems within an internal network. Whether external attacker or rogue employee, password guessing is simple!
2. Inappropriate Privileges
Life is made much easier for an attacker when permissions and privileges are attributed inappropriately. Dionach often finds a high number of users in the Domain Admins group, test accounts with full administrator access, service accounts running with full privilege on the system or domain, redundant accounts that are still enabled and have access to live systems, and data that is easily accessible without appropriate control. Not keeping a good handle on privilege management leads to inappropriate access to resources.
3. Access Control Issues / Information Leakage
ess emphasis is often placed in an internal network on locking things down, hardening systems and restricting access to services and system information. The internal network is a feast of information for someone who can gain access to it. Even a quick inspection of the internal network can uncover information or credentials that can be used to compromise systems. Examples include unencrypted Excel spreadsheets listing passwords, unprotected batch files containing admin credentials, backups of databases, virtual machines or mailboxes copied “temporarily” to an unsecured network share, database connection strings freely available, and more. If you look for long enough through network shares, the information is there for the taking.
4. Inadequate Patching of Systems
Patching is an age old problem: how to apply critical security patches to live systems in a timely manner without affecting the availability of the system. Although many organisations seem to place a good emphasis on managing operating system security updates using systems such as WSUS, many other third party software is installed and forgotten about, slowly accumulating vulnerabilities over time. Similarly with device firmware, without an adequate procedure to monitor and update firmware, the device is often installed and only revisited when there is a functionality issue with it. For as long as internal systems remain unpatched, there is a potential for them to be exploited by an internal attacker.
5. Unsecured Workstations
“It’s only a workstation, there’s nothing sensitive stored on it.” is something we often hear. However, a workstation can be a key starting point to target a network. The all too familiar combination of an unencrypted Windows workstation that can be booted to alternate media such as Kali Linux gives so many possibilities to target the Windows domain or other systems. Extracting credentials from the SAM database, discovering credentials in installation files or leveraging inappropriate account privileges can often lead to full domain compromise.
6. Vulnerabilities in Intranet Applications
Security testing externally available web applications is a common part of the security program of many organisations. However, internal applications are often overlooked in this process, again because the internal location is perceived as being safe. The problem with many internal applications is that not only do they often contain more vulnerabilities than their externally available counterparts, they have a number of other factors that are interesting to an attacker: they are often installed on internal domain resources, often running on servers without adequate malware protection, often running with inappropriately privileged service accounts and rarely separated from the rest of the network. For example, a SQL injection vulnerability on an internal application often leads not only to a compromise of the sensitive data held in its databases, but often to a compromise of other systems and full domain control.
As for a list of exploits, many of the above examples can lead to system compromise on their own. However, a typical “sophisticated” compromise of a system invariably includes many, if not all, of the categories above.
So what can be done? Internal penetration testing will find and highlight these vulnerabilities. However, without good supporting policy and procedure, the root cause of such issues may remain and vulnerabilities will reoccur over time. ISO 27001 provides an excellent framework to put procedures in place to tackle some of these issues, for example sections A10 on Communications and operations management, and A11 on Access control. What is clear is that internal networks are not safe from hackers and companies need to recognise and act on this risk.